The present invention relates to an electronic apparatus forming a sensor, an actuator or a control and comprising a control engine as well as an integrated bus interface via which the apparatus can be connected to a data bus for the communication of the apparatus with at least one further apparatus forming a sensor, an actuator or a control and connected to the data bus and comprising a device-specific definition engine in which parameters required for the communication and/or configuration of the electronic apparatus are stored, with the device-specific definition engine being present in a device-specific format and the parameters being able to be accessed via the control engine.
In many areas of application of automation technology, different devices nowadays communicate with one another via a bus system. A plurality of different bus systems are known based on different communication protocols. Starting with the physical layer, up to the application interface of the individual devices, the fieldbus specifications are each specifically defined in accordance with their area of application.
On the integration of a device into a larger automation solution, a large amount of information has to be exchanged between the individual components via the data bus. Depending on the respective component, the contents of these pieces of information can be very different. These pieces of information can thus, for example, relate to the topological system structure, to parameters of the communication behavior or even to visualization properties for a configuration program (engineering tool). The information required by the surrounding system is as a rule provided via a file which contains a device description. This device description is dependent on the respective device and is also termed a device-specific definition engine within the framework of this application. The device description is present in a device-specific format so that a technical program evaluation of the device description is possible. Since this device-specific format is not universal, but differs from system to system, the required device description must be prepared new in each case for the integration of a device into a specific environment. For this purpose, the developer also requires, in addition to his device-specific technical knowledge, very far-reaching know-how of the respective description language used.
A further problem lies in the fact that the allocation of parameters and functions to specific variables, addresses or channels is usually carried out in so-called profiles (device profiles) with different fieldbuses. These profiles are, however, not only dependent on the respective fieldbus, but also on the respective area of application. If a device should be used in different application fields, an adaptation of the application to the respective profile must be carried out in every single case. This also applies in particular when the standard underlying the profile is changed. Even when no change takes place in the physical bus used, a given object in the device can be mapped on different structures in dependence on the respective application.
If a device should be used in a new field of application or if the definition of the application profile changes, it is therefore necessary to make adaptations to the control engine of the device. These adaptations require detailed knowledge both of the device and of the application profile.
So that a device (sensor, actuator or control) in automation technology can be operated at any desired communication connection (for example a sensor connection to a fieldbus), the device has to be specifically configured for this. Devices which have no display of their own or corresponding input elements require external configuration software (operation software) for the configuration in connection with a description of the device properties. If this description is not present, communication between the configuration software and the device is not possible. If new device variants are introduced it is therefore imperative for the configuration software to be adapted to this new device variant and correspondingly updated.
A further problem area lies in the fact that numerous dependencies between the device parameters have to be taken into account on the parameterization (configuration) of field devices. Specific values or value ranges are under certain circumstances only permitted for individual parameters when other parameters have specific pre-determined values. There is thus a dependency between individual device parameters. The device must therefore check, in particular after a change of device parameters, whether the new parameter set totally satisfies all pre-determined conditions. If at least one of the pre-determined conditions is infringed, it is necessary to change into a suitable error state.
It is sensible that on a parameterization via a configuration tool (on a computer) this configuration tool already checks all pre-determined conditions and also emits a warning on the monitor, where necessary, even with a non-connected device, after the input of corresponding erroneous parameters. Since the corresponding checks are usually programmed in the configuration program independently of the corresponding checks within the devices, it is not precluded that there are differences in the evaluation of the conditions to be checked due to erroneous programming. A parameter set accepted by the configuration software as permitted in the development phase can thus result in a standstill of the device or in another error in operation. Furthermore, the double provision of the corresponding software parts inside the device and inside the configuration software is complex and causes additional costs. The double programming is in particular seen as necessary since the corresponding program parts run on different platforms (different hardware, different programming languages), namely on the one hand inside the device and on the other hand inside the configuration software on a computer, for example on a PC or on a handheld (PDA).